home *** CD-ROM | disk | FTP | other *** search
/ Celestin Apprentice 4 / Apprentice-Release4.iso / Source Code / Libraries / VideoToolbox 95.11.08 / Video synch < prev   
Encoding:
Text File  |  1995-11-08  |  56.7 KB  |  64 lines  |  [TEXT/R*ch]

  1. s
  2. immediately, letting the video card processor do the work later, at vbl time.
  3. And SetEntriesQuickly.c, for the few devices that it supports, allows you to
  4. achieve whatever behavior you want. Those solutions will make your code highly
  5. dependent on the particular video card. One solution that might work on all
  6. video cards would be to only call the video driver (e.g. GDSetEnries) during
  7. vertical blanking, i.e. immediately after the vbl interrupt occurs (use
  8. VBLInstall.c).
  9.      Michael Bach (bach@sun1.ruf.uni-freiburg.de) adds, "We have since done
  10. more experiments. We have an A/D card from National Instruments (NB-MIO-16),
  11. which we use with LabView. National Instruments also provide a library of
  12. lower-level routines ("NI-DAQ"), namely one "SCAN" that regularly scans analog
  13. input and writes into a buffer in memory. As the card lacks DMA, this is --
  14. reading between the lines of their documentation -- implemented by an interrupt
  15. service routine called at the end of conversion. For this, the "NB-Handler Init"
  16. must be installed when the system is started up. While interrupts are blocked,
  17. measurements are kept in a FIFO on the card. If we use their SCAN routine,
  18. sampling is performed smoothly and not blocked by AnimatePalette et al.  But care
  19. has to be taken that the FIFO is not overrun." This confirms that the video
  20. driver blocks all interrupts. Any interrupt that's still asserted will occur when
  21. the video driver exits. The timer interrupt is asserted only briefly and is lost
  22. if not serviced promptly; apparently the A/D card's slot interrupt request
  23. remains asserted until serviced.
  24.  
  25. C. CONTROLLING THE COLOR LOOKUP TABLE (CLUT)
  26.  
  27. QuickDraw is one of the great virtues of the Macintosh. However, several of its
  28. assumptions about what you want are inappropriate for vision experiments. In
  29. particular, it assumes that you want all your monitors to act as one consistent
  30. desktop (with consistent color tables). This is a problem if you want to load
  31. completely independent lookup tables and images onto two monitors that, for
  32. example, you may want to superimpose optically. QuickDraw enforces the
  33. consistency throught the Palette Manager, but calls that are nominally to the
  34. Color Manager (e.g. Apple's SetEntries) may be intercepted by the Palette
  35. Manager, resulting in undesired effects on other screens. My solution is to
  36. bypass QuickDraw and to load the lookup tables more or less directly, without
  37. telling QuickDraw.
  38.  
  39. GDSetEntries() and SetEntriesQuickly() work outside of QuickDraw. GDSetEntries
  40. makes a cscSetEntries control call to the video driver; SetEntriesQuickly
  41. directly addresses the hardware. They both load the clut of the video card
  42. without changing the color spec table of the graphics device; QuickDraw will
  43. continue to assume that the graphics device's color spec table is a true copy of
  44. the clut. This is the behavior that I usually want. However, it may cause
  45. problems if you use CopyBits since CopyBits will translate the color of each
  46. pixel it copies, using the inverse color table of the current device, which is
  47. based on the color spec table, NOT the clut. If you want to use CopyBits or
  48. SetCPixel, you should copy your color spec table into the graphics device's color
  49. spec table, and set ctSeed to alert QuickDraw that it's been changed. Or, instead
  50. of using QuickDraw's CopyBits and SetCPixel, you could use the VideoToolbox's
  51. CopyBitsQuickly and SetPixelsQuickly(), which copy pixel walues directly,
  52. ignoring all color tables and inverse color tables.
  53.  
  54. D. HIGH FRAME RATES
  55.  
  56. On March 17 fifty of us sent a letter to Apple--see "cscSetModeTiming.doc" in the
  57. "Notes" folder--requesting a new feature for video drivers to support arbitrary
  58. frame rates and resolutions. High frame rates are particularly relevant to stereo
  59. (using LCD glasses to alternate eyes) and retinal physiology (because retinal
  60. ganglion cells respond up to 100 Hz).
  61.  
  62. For some vision experiments it is desirable to run at very high frame rates, e.g.
  63. 100 or even 200 Hz for retinal physiology experiments. There exist special
  64. monitors, e.g. the Joyce DM-4 Display, that run at such hig